what happens in the new Git folders case? Does the CLI successfully read GitInfo from the local .git? Can we add some acceptance test coverage for all three cases (new git, classic repo, and vanilla). You can mock the API endpoints.

On DBR this code never read locally, see this guard

That also make it harder to test with acceptance tests as we can't properly mock the environment

I added some unit tests

With new git folders API returns only gitInfo.ID

See example

🔴 workspace/get-status doesn't return git provenance for git-in-data-plane folders

  Same repo (github.com/databricks/bundle-examples), same path, two workspaces — different
  result.

  ① AWS staging — git-in-DP folder (object_type: DIRECTORY)

  Request:
  GET /api/2.0/workspace/get-status
        ?path=/Workspace/Users/<user_name>/bundle-examples
        &return_git_info=true
  Response:
  {
    "object_type": "DIRECTORY",
    "git_info": {
      "id":   2884540697170475,
      "path": "/Users/<user_name>/bundle-examples"
    }
  }
  ❌ missing branch, head_commit_id, url, provider

  …yet the data does exist — same id, Repos API:
  GET /api/2.0/repos/2884540697170475
  {
    "branch":         "main",
    "head_commit_id": "d53214e177cd372afa03bfc044be9bb94103ba9a",
    "url":            "https://github.com/databricks/bundle-examples.git",
    "provider":       "gitHub"
  }
  ✅ full provenance

There must be a way to read the commit ID? From the .git folders directly maybe as we do locally?

This can be a followup to this PR - but capturing Git metadata from Git folders is an important usecase? Since DABs in the workspace is supported there?

This can be a followup to this PR - but capturing Git metadata from Git folders is an important usecase? Since DABs in the workspace is supported there?

It's important — and this PR already covers it, so it doesn't need to be a followup. To clarify the scope:

• This only affects bundles deployed from the workspace. Local and CI/CD deploys are unaffected — they read .git directly
• We already supported two object types: classic Repos and Git folders. Both return the full git_info inline from Workspace get-status API, so they work correctly today
• The gap is a new Private Preview feature, Git in Dataplane. Objects created with that flag don't return a full git_info from get-status — only git_info.id (the repo id) — and there's no .git directory to read on the Dataplane either
• This PR handles that case: it takes the id and calls the Repos API (GET /api/2.0/repos/{id}) to recover branch/commit/url. So Git metadata ends up captured for all of them

I'll check if it's possible to add acceptance test using RunOnDbr